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This  document  was  prepared  by  the  University  of  Houston,  Houston,  Texas, 
on  Air  Force  Contract  No.  F33615-80-C-1095,  entitled  "The  Remote  Link  Unit  -  A 
Demonstration  of  Operational  Performance." 

The  work  was  administered  under«<^e  direction  of  the  Information  Transfer 
Group,  Information  Processing  Technology  Branch,  System  Avionics  Division  of 
the  Avionics  Laboratory,  under  Project  2003,  "Avionic  System  Design 
Technology,"  Task  08,  "Multiplex  and  Information  Transfer  Technology,"  Work 
Unit  07,  "Remote  Link  Unit  Demonstration."  The  work  was  performed  during  the 
period  1  April  1980  to  31  December  1980  and  this  report  was  submitted  in 
August  1981.  The  Air  Force  Project  Engineer  was  Philip  C.  Goldman 
(AFWAL/AAAT-3) . 

The  work  is  a  continuation  of  a  previous  feasibility  study  entitled,  "The 
Remote  Link  Unit:  An  Advanced  Remote  Terminal  for  MIL-STD-1553A. "  The 
results  of  this  study  are  documented  in  a  technical  report  entitled,  "Remote 
Link  Unit  Functional  Design:  An  Advanced  Remote  Terminal  for  MIL-STD-1553B," 
which  was  published  as  AFAL-TR-79~1176,  AD-A080126.  An  add-on  to  this  pre¬ 
vious  study  resulted  in  a  second  technical  report  entitled,  "The  Remote  Link 
Unit:  Applications  to  the  Design  for  Repair  Methodology  Program,"  published 
as  AFWAL-TR-80-1033,  AD-A086126. 

This  report  summarizes  the  design,  development,  and  testing  accomplished 
under  the  contracted  work.  The  Principal  Investigator  and  Program  Manager  was 
Dr.  Carlos  J.  Tavora.  Drs.  John  Glover,  Jr.  and  Miles  A.  Smither  were  Co- 
Investlgators.  Dr.  tavora  was  responsible  for  the  system  'architecture  and 
modularization  of  the  design.  Dr.  Glover  supervised  the  design  of  the  soft¬ 
ware  for  the  Link  Manager  Simulator  and  the  Link  Module.  He  was  assisted  by 
Messrs.  Hao-Cheng  Hsla,  William  C.  LaWj^  and  Parmanand  Balsaver.  Dr.  Smither 
was  assisted  by  Mr.  Tzer-Tsan  Lin  in  tHe  design  of  the  Interface  Configuration 
Adapter.  Mr.  H.  Mitchell  Collins  was  in  charge  of  the  design  of  the 
Electronic  Nameplate  and  fhd  Nameplate  Interface  Controller. 

This  report  is  organized  in  three  parts:  Part  I  -  Summary,  Part  II  - 
User's  Manual,  and  Part  III  -  Design  Manual.  Part  III  is  separated  into  two 
volumes:  Volume  1  is  the  main  body  of  the  Design  Manual,  while  Volume  2 
contains  the  appendices. 

This  part  is  organized  as  a  short  summary  of  the  Remote  Link  Unit 
Demonstration  project,  with  an  overview,  and  including  design  enhancements  and 
an  implementation  plan  for  RLU  development.  A  brief  summary  of  test  results 
is  also  Included. 


TAB1£  OF  CONTENTS 


! 


SECTION 

1.  INTRODUCTION  . 

1.1  BACKGROUND 


1.1.1  Electronic  Nameplate  .  .  . 

1.1.2  Link  Module  . 

1.1.3  Link  M2mager  . 

1.2  OBJECTIVES  AND  APPROACH  .  .  .  . 


1.2.1  Approach 

1.3  DELIVERABLES 


1.3.1  Hardware  . 

1.3.2  Software  . 

1.3.3  Documentation  . 

1 .3 .3 . 1  Design  Manual  .  .  . 

1.3 .3. 2  User's  Manual  .  .  . 

1.3. 3. 3  Test  Plan  . 


2.  FUNCTIONAL  DESIGN  ENHANCEMENTS  .  .  .  . 

2.1  LINK  NODULE  AND  LINtC  MANAGER  .  .  . 

2.1.1  Mapping  EAROM  Changes  .  .  . 

2.1.2  Shared  Memory  Handshake  .  . 


2.2  INTERFACE  CONFIGURATICR)  ADAPTOR  . 


2.2.1  Signal  Interface  .... 

2.2.2  Output  Sigtuil  Multiplexing 


2. 2. -3  AC  Reference  Signal 

2.2.4  Synchro  Reference  .  . 

2.2.5  Serial  Input  Handshake 


SECTION 


2.2.6  Interface  Buffer  Design . . . 12 


2.2.7  Output  Autonatlc  Scaling  . 12 

2.3  SUBSYSTEM  INFOBMATION  CHANNEL . 12 

2.3.1  Nameplate  Clock . 12 


2.3.2  Nameplate  Coemands 


2.3.3  Nameplate  Architecture 


2.3.4  Nameplate  Diagnostic 


3.  IMPLEMENTATION  PLAN . 17 

3.1  C»JECTIVES  AND  APPROACH . 17 


3.1.1  Phase  I  >  RLU  Integration 


3.1.2  Phase  II  -  RLU  Distribution 


3.2  DESIGM  AND  IMPLEMBNTATIOM  CONSIDBRATIOMS . 19 


3.2.1  ICA 


3.2.2  Subsystem  Zafommition  Channel . 21 

3.2.3  Link  Nodule . 21 

3.2.4  Link  Manager . 21 

4.  TESTS  AND  RESULTS . 22 

4.1  TEST  PROCEDURE . 22 


4.1.1  ICA  Tests 


4.1.2  SIC  Testa 


4.1.3  RLU  Tssts 


4.2  TEST  RESULTS 


4.2.1  ICA  Testa 


4.2.2  SIC  Tssts 


4.2.3  LN  Tests 


5.  COMCLUSIOMS . 27 


▼1 


LIST  OF  ZLLUST1ATI(»1S 


figure  PAGl 

1  RLUDS  Implementation  of  RLU . 4 

2  RLUDS  Configuration  .  4 

3  Format  of  Mapping  EAROM  Entry  ...  .  8 

4  Data  Transfer  H^uldshake  Protocol . 

5  ICA  Signal  I/O  Connections  . 11 

6  Analog  and  Digital  Output  Multiplexing  . 11 

7  Flag  Mode  Serial  Input  Handshake  . 13 

8  New  Commamd/Response  Protocol  . 15 

9  RLU  Implementation  Chart . 18 

10  Avionic  System  Architecture  . 20 

LIST  OF  TABLES 

TABLE  PAG 

1  Nauneplate  Commands . 15 

2  Response  Time  of  Commands . .25 

3  Execution  Time  of  Gcnnaands . 26 


vil 


LIST  OF  ACROI^S 


AC 

Alternating  Current 

A/D 

Analog  to  Digital 

BCD 

Binary  Coded  Decimal 

CMOS 

Complementary  Metal  Oxide  Semiconductor 

CPU 

Central  Processing  Unit 

CRT 

Cathode  Ray  Tube 

D/A 

Digital  to  Analog 

DC 

Direct  Current 

DIP 

Dual  In-line  Package 

DMA 

Direct  Memory  Access.. 

EAROM 

Electrically  Alterable  ROM 

EEPR(»1 

Electrically  Erasable  Programmable  RON 

EPROM 

Erasable  Programmable  ROM 

FP 

Front  Panel 

ICA 

Interface  Configuration  Adapter 

I/O 

Input /Output 

ISR 

Interrupt  Service  Routine 

LA 

Link  Address 

LM 

Link  Module 

LMG 

Link  Manager 

LMP 

LM  Processor 

LSB 

Least  Significant  Bit 

MP 

Maintenance  Port 

MSB 

Most  Significant  Bit 

MUX 

Multiplexer 

NIC 

Nameplate  Interface  Controller 

NP 

Nameplate 

PCB 

Printed  Circuit  Board 

PIA 

Peripheral  Interface  Adapter 

PROM 

Programmable  Read  Only  Memory 

RAM 

Random  Access  Memory 

RLU 

Remote  Link  Unit 

RLUDS 

Remote  Link  Unit  Demonstration  System 

RMW 

Read-Modlfy-Write 

ROM 

Read  Only  Memory 

RT 

Remote  Terminal 

SIC 

Subsystem  Information  Channel 

SM 

Shared  Memory 

SRU 

Shop  Replaceable  Unit 

TTL 

Transistor-Transistor  Logic 

UFT 

User  File  Table 

vlii 


SECTION  1 


INTRODUCTION 


This  report  describes  the  results  of  a  program  of  implementation  of  a 
RLU  Demonstration  System  (RLUDS).  The  Remote  Link  Unit  (RLU)  is  a  new  de¬ 
sign  concept  for  remote  terminals  which  is  based  on  the  remote  terminal 
developed  under  the  Avionics  Laboratory's  Digital  Avionics  Information 
System  (DAIS)  program.  Design  of  the  RLUDS  is  based  on  the  functional  de¬ 
sign  described  in  the  document  "Remote  Link  Unit  Functional  Design:  An 
Advanced  Remote  Terminal  for  MIL-STI>-1553B,"  [1],  The  RLUDS  is  not  intend¬ 
ed  to  be  a  conplete  RLU  prototype  but  it  demonstrates  the  most  unique  parts 
of  the  RLU.  The  RLUDS  is  an  experimental  device  that  provides  operational 
performance  data  on  the  RLU  and  has  facilitated  the  resolution  of  problem 
areas  in  the  RLU  design. 


1.1  BACKGROUND 

Remote  terminals  (RTs)  are  used  extensively  in  the  current  military 
aviation  electronics  area.  Typically,  an  aircraft  will  contain  a  central 
computer  and  several  remotely  located  avionic  subsystems  (radar,  radio, 
navigation  set,  controls  and  displays,  etc.).  The  coamiunication  between 
the  central  computer  and  the  subsystens  is  effected  through  a  time-division 
multiplex  data  bus,  such  as  MIL-STI>-1S53B.  Remote  subsystems  are  connected 
to  the  bus  through  remote  terminals,  which  have  several  functions: 

e  Sending  and  receiving  messages  of  data  and  commands  over  the  bus 
in  the  proper  standard  bus  protocol, 

e  Responding  to  commands  from  the  central  computer, 

e  Sending  and  receiving  signals  to  the  subsystem  in  the  proper 
format  for  that  particular  subsystem,  and 

e  Napping  of  subsystem  addresses  to  the  particular  data  chcuuiels 
for  the  various  subsystems. 

The  Remote  Link  Unit  (RLU)  is  cosqpar«d>le  to  the  DAIS  remote  terminal 
upon  which  it  is  based,  but  it  is  not  limited  to  being  a  replacement  of  the 
DAIS  terminal,  it  is  a  collection  of  diverse  and  interacting  logical  and 
processing  functions  that  inpact  all  types  of  avionic  data  communication. 

The  RLU  can  be  described  in  terms  of  three  major  components:  the  Electronic 
Nameplate,  the  Link  Nodule,  zmd  the  LiiJc  Nanager. 

1.1.1  Electronic  Nameplate 

The  electronic  nameplate  (NP)  is  a  non-volatile  amd  electrically 
alterable  digital  memory  that  can  store  information  during  a  mission  and 
save  it  until  it  is  needed.  It  also  has  non-alterable  memory,  as  required. 
The  electronic  nameplate  is  a  part  of  the  RLU  but  is  physically  attached  to 
the  svdbsystem.  It  contains  information  that  can  be  read  on  demand,  such  as: 


•  Subsystem  identification  (type,  model,  serial  number,  etc.}, 
e  Subsystem  function, 
e  Physical  location  of  subsystem, 

e  Interface  specification  (level,  timing,  handshaJcing,  rate,  etc.), 
e  Operational  history  (calibration,  mainten£uice,  etc.),  and 
e  Configuration  programs. 

The  configuration  programs  are  loaded  into  the  RLO's  processor  to 
enable  it  to  communicate  with  the  subsystem.  These  can  include  initialisa¬ 
tion,  data  conversion,  calibration,  and  diagnostic  programs. 


1.1.2  Link  Module 

The  Link  Module  (LM)  can  replace  15  of  the  17  different  interface 
modules  of  the  DAIS  RT.  The  Link  Module  is  a  standeurd  hardware  unit  that 
contains  a  processor  with  three  interfaces:  the  Interface  Configuration 
Adapter  (ICA) ,  the  Nameplate  Interface  Controller  (NIC) ,  and  the  Shared 
Memory  (SM) . 

The  Interface  Configuration  Adapter  is  the  device  that  inplements 
the  "universal  interface"  of  the  RLU..  Under  software  control,  it  configures 
itself  to  the  prqper  interface  specification  for  comnunication  with  the 
subsystem. 

The  Nameplate  Interface  Controller  provides  RLU  access  to  the  elec¬ 
tronic  nameplate  attached  to  a  subsystem.  Through  the  NIC  the  Ui  processor 
retrieves  identification,  configuration  parameters  and  data  conversion 
programs  related  to  the  subsystem. 

The  Shared  Memory  implements  the  interface  between  the  Link  Module 
and  the  Link  Manager.  It  provides  for  the  storage  of  commands,  status, 
data  and  handshake  flags. 

The  processor  supports  the  overall  operation  of  the  LM  performing 
the  processing  of  programs  that  support  the  operation  of  the  subsystem  and 
the  LM  interfaces. 


1.1.3  Link  Manager 

Ihe  Link  Manager  (LMG)  is  the  sipervisor  of  the  RLU.  The  IMG  con¬ 
tains  processing  and  memory  and  supports  the  overall  operation  of  the  RLU, 
including  comnninicationj  resource  control i  redundancy  aanagement  (of  dual 
buses  or  dual  power  supplies,  for  example);  fault  detection,  isolation,  and 
recording;  and  data  conversion.  In  addition,  it  has  the  potential  capability 
to  control  the  RUJ  and  its  svd»systems  in  a  stand-alone  fashion,  in  the  event 
of  loss  of  cosonmication  with  the  central  computer,  due  to  hardware/softmre 
failure  or  perhaps  even  battle  damage.  This  clustering  of  functions  could 
greatly  mshanoe  the  survivability  of  digital  avionic  systems  in  future  air- 


1.2  OBJECTIV  S  AND  APPROACH 


The  RLU  Demonstration  System  (RLUDS)  was  built  to  achieve  three  objec¬ 
tives  : 

e  Demonstrate  the  RLU  concepts  in  operation, 

e  Support  the  design  of  an  RLU  prototype,  and 

a  Design  the  SIC  and  the  ICA  as  stand-alone  avionic  system  components 

Design  of  an  RLU  prototype  requires  that  the  feasibility  of  implemen¬ 
tation  of  RLU  concepts  be  demonstrated  beyond  a  functional  design.  Some  of 
the  RLU  concepts  require  hardware  and  software  designs  vdiich  are  not  con¬ 
ventional.  Construction  and  operation  of  the  demonstration  system  was 
essential  to  the  identification  and  solution  of  problems  not  uncovered  in 
the  functional  design. 


1.2.1  Approach 

The  RLUDS  implementation  of  the  RLU  concentrates  on  the  Link  Module 
and  its  interfaces  as  depicted  in  Figure  1.  The  following  RLU  components 
required  special  design  and  fabrication: 

•  Link  Module  (LM) , 

e  Subsystem  Information  Channel  (SIC)  and  Electronic  Nameplate  (NP) , 

e  Interface  Configuration  Adapter  (ICA) ,  and 

•  Shared  Memory  (SM)  interface  between  the  LM  and  the  Link  Manager 
(LMG) . 

The  Link  Mcuiager  (LMG)  was  simulated  with  a  PDP>ll/70,  while  the  LM 
was  inplemented  with  a  Motorola  6800  microprocessor  and  the  NP  utilized  a 
Motorola  6801  microprocessor.  The  architecture  of  the  RLUDS  is  shown  in 
Figure  2. 


1.3  DELIVERABI£S 

The  RLU  Demonstration  System  consists  of  hardware,  software  euid  docu¬ 
ments  as  described  below. 


1.3.1  Hardware 

The  hardware  of  the  RLUDS  includes  the  following  items: 

•  One  Link  Module  with  processor,  memory,  three  interface  cards  and 
power  supply.  The  link  module  is  housed  in  a  two-chassis  enclosure 
equipped  with  connectors  and  a  front  panel  display  module. 


Figure  1  RLUDS  Implementation  of  the  RLO 


LINK  MANAGER  (LMO) 
SIMULATOR 


Figure  2  RLUDS  Configuration 
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•  Two  electronic  nameplates  that  interface  to  the  LM  through  a  Sub¬ 
system  Information  Channel  (SIC) . 

•  Two  distinct  subsystems  that  can  be  used  to  demonstrate  the  pro¬ 
cessing  and  interfacing  capabilities  of  the  RLU.  One  subsystem 
contains  two  synchros  which  are  used  as  input  and  output  devices. 
The  other  subsystem  requires  a  serial  digital  interface  to  support 
switches  as  input  devices  and  a  four  digit  display  as  an  output 
device.  The  serial  input  cam  operate  in  either  flag  or  refresh 
mode. 

•  A  Test  box  that  exercises  the  ICA  by  generating  and  detecting 
signals  corresponding  to  15  different  interface  modules  utilized 
by  DAIS. 

a  A  set  of  cables  to  interface  the  LM  with  its  subsystems  and  the 
PDP-11/70  LMG  simulator. 


1.3.2  Software 

Two  tapes  containing  RLUDS  software  are  delivered  with  the  system. 
Both  tapes  are  recorded  on  9  tracks  with  800  bpi  density  using  DOS  (DEC) 
format.  The  first  tape  -  labeled  "RLUDS  Source  Software"  -  contains  soft¬ 
ware  for  the  Link  Manager  simulator,  the  Link  Module  and  the  Electronic 
Nameplate.  The  second  tape  -  labeled  "RLUDS  Installation  Tape"  -  is  used 
to  install  the  Link  Manager  software  on  a  PDP-11/70  series  host  computer. 


1.3.3  Documentation 

Three  docianents  are  part  of  the  RLU  demonstration  system.  These 
documents  are  as  follows: 

1.3. 3.1  User's  Manual 

Part  II  of  this  document  contains  the  User's  Manual  for  the  RLU 
Demonstration  System.  This  manual  describes  how  the  system  should  be  set 
up  for  operation,  emd  presents  a  tutorial  on  the  use  of  the  IMG  nan-machine 
interactive  dialogue  program.  Utilization  of  the  LM's  front  panel  controls 
and  displays  is  also  included.  Test  scripts  designed  to  exercise  all  RLUDS 
fiinctions  are  also  included. 

1.3. 3. 2  Design  Hemual 

Part  III  of  this  document  contains  the  Design  Manual  for  the  RLU 
Demonstration  System.  This  manual  presents  a  detailed  description  of  the 
hardware  and  software  utilized  in  the  implementation  of  the  system.  The 
theory  of  operation  of  all  system  modules  is  presented  and  the  interaction 
between  hardware  wd  software  is  described.  This  manual  is  in  t%io  volumes. 
Volume  1  is  the  basic  Design  Manual  and  Volume  2  is  the  Appendices  A,  B, 


1.3. 3. 3  Test  Plan 


The  document  "Test  and  Acceptance  Plan  for  the  RLU  Demonstration 
System,"  [2],  outlines  a  test  procedure  to  evaluate  all  major  RLU  Demon¬ 
stration  system  components.  The  test  plan  Incorporates  three  sets  of  tests: 
RLU  tests,  ICA  tests,  and  SIC  tests. 

The  RLU  tests  are  tests  designed  to  demonstrate  the  performance  of 
the  RLU  as  a  system.  In  these  tests,  the  Link  Manager  interacts  with  the 
Link  Module  to  control  a  subsystem.  Failures  Induced  in  the  subsystem 
demonstrate  the  fault  monitoring  and  recording  capabilities  of  the  RLU. 

The  ICA  tests  demonstrate  the  performance  of  the  ICA  as  a  universal 
interface  module. 

The  SIC  tests  demonstrate  that  the  Subsystem  Information  Channel 
is  a  viable  distributed  memory  device  that  supports  the  recording  of  sub¬ 
system  faults  and  is  compatible  with  the  retrieval  of  maintenance  data  at  a 
later  time. 
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SECTION  2 


FUNCTIONAL  DESIGN  ENHANCEMENTS 


During  the  development  of  the  rluds,  several  new  features  were  included 
which  are  now  proposed  as  enhancements  to  the  previous  RLU  design.  Changes 
to  the  RLU  Functional  Design  [1]  necessary  to  incorporate  these  enhancements 
are  outlined  below. 


2.1  LINK  MODULE  AND  LINK  MANACXR 

The  only  changes  to  the  Functional  Design  in  the  chapters  describing 
the  LM  amd  the  LMG  relate  to  an  enhancement  which  provides  a  more  flexible 
message  tremsfer  capability.  Previously,  t%»o  data  transfer  buffers  were 
required  in  shared  memory  to  allow  all  data  transfers  to  be  double-buffered. 
Realizing,  however,  that  not  all  messages  possess  the  real-time  urgency  re¬ 
quiring  double-buffering,  the  message  exchange  protocol  was  enhanced  to 
allow  the  option  of  single  or  double  buffers.  VRien  double-buffering  is 
selected,  data  tramsfer  is  essentially  as  described  in  the  Functional  Design. 
VA)en  single-buffering  is  selected.  Buffer  0  can  be  used  for  output  while, 
concurrently.  Buffer  1  is  used  for  input.  This  option  increases  the  utility 
of  the  shared  memory  buffers. 

The  effect  of  this  enhancement  on  the  Functional  Design  is  to  change 
those  sections  which  describe  the  data  transfer  protocol. 


2.1.1  Mapping  EAROM  Changes 

Section  6.1.3  of  the  Functional  Design  describes  the  mapping  EAROM 
in  the  LMG.  ^is  table  remains  unchanged  except  for  a  modification  of  two 
bits  in  each  i6-bit  entry  in  the  EAROM.  The  format  of  each  map  entry,  as 
illustrated  in  Figure  37  of  the  Functional  Design,  should  be  modified  to  be 
as  shown  in  Figure  3.  The  S/D  bit  indicates  whether  single  or  double¬ 
buffering  is  selected  for  this  message.  The  S/R  bit  indicates  whether  the 
message  is  a  sequential  or  refreshed  type  of  message.  The  distinction  be¬ 
tween  sequential  and  refreshed  is  described  below. 


2.1.2  Shared  Memory  Handshake 

Sections  3.1.3  and  6.2.4  of  the  Functional  Design  describe  the  hand¬ 
shake  in  shared  memory  which  implements  the  data  transfers.  This  handshake 
is  now  modified  to  allow  the  enhancements  described  earlier.  The  new  hand¬ 
shaking  protocol  is  described  here: 

First,  two  types  of  I/O  are  provided  for:  sequential  and  refreshed. 

A  sequential  message  is  placed  once  into  the  shared  memory  buffer  and  must 
be  received  and  acknowledged  to  avoid  an  error  condition.  In  DAIS,  all  out¬ 
put  messages  are  sequential  and  all  asynchronous  input  messages  are  sequen¬ 
tial.  A  refreshed  message  is  one  in  which  the  data  is  simply  kept  up-to-date 
in  the  shared  memory  buffers  and  is  only  occasionally  received.  A  message 
is  overwritten  by  a  svdbsequent  message  without  causing  an  error  condition. 

In  DAIS,  synchronous  input  Mssages  are  refreshed. 
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S/D  =  Single-/double-buff ered 
S/R  =  Sequential/refreshed 
EOM  s  end  of  message 
WSC  =  word  subcount 
LM  =  link  module  no. 

LA  =  link  address 


Figure  3 


Format  of  Mapping  EAROH  Entry 


Second,  the  data  transfer  status  word  has  been  slightly  rearranged 
to  accomnodate  the  new  I/O  features.  Figure  4  illustrates  the  new  handshake 
protocol  and  replaces  Figure  13  of  the  Functional  Design.  After  conunand 
byte  C0  is  written  to  shared  meinory,  the  LMG  performs  a  read-modify-write 
operation  on  status  byte  SI.  After  the  read  portion,  the  LMG  checks  the 
RDy0  and  the  RDYl  bits.  For  single-buffered  I/O,  RDy0  will  be  set  if  the 
output  buffer  is  available  and  RDYl  will  be  set  if  the  input  buffer  is 
available.  For  double-buffered  I/O,  the  RDY0  and  RDYl  bits  indicate  which 
of  the  two  buffers  is  available.  In  either  case,  if  a  buffer  is  available, 
the  LMG  sets  the  REQ0  or  REQl  bit  to  indicate  which  buffer  is  taken  and 
writes  the  SI  byte  back  to  shared  memory  to  complete  the  read-modify-write. 
The  LMG  then  writes  the  S0  byte  to  shared  memory  to  indicate  the  number  of 
words  to  be  involved  in  the  data  transfer.  Other  details  of  the  handshake, 
such  as  the  use  of  command  bytes  C0  and  Cl,  remain  unchanged. 


2.2  INTERFACE  CONFIGURATION  ADAPTOR 

Development  of  the  detailed  design  for  the  Interface  Configuration 
Adaptor  led  to  modifications  of  the  functional  design  that  enhance  the  op¬ 
eration.  These  modifications  are  outlined  below. 


2.2.1  Signal  Interface 

In  view  of  the  high  resistance  associated  with  solid-state  switches, 
it  was  necessary  to  provide  a  direct  current  path  for  the  single-ended  con¬ 
nection.  With  the  new  design,  the  differential  output  is  applied  to  the 
subsystem  through  the  two  differential  drivers  of  the  signal  I/O  section  of 
the  ICA.  The  single-ended  output  is  available  between  the  positive  driver 
and  ground.  A  diagram  depicting  the  connections  for  the  single-ended  and 
differential  outputs  is  illustrated  in  Figure  5. 


2.2.2  Output  Signal  Multiplexing 

The  generation  of  analog  and  digital  output  signals  described  in  the 
functional  design  utilizes  a  digital  multiplexer  to  select  digital  data 
corresponding  to  analog  or  digital  values  for  the  D/A  converter.  A  more 
effective  scheme  which  reduces  the  number  of  lines  used  was  implemented. 
This  design  utilizes  an  analog  multiplexer  to  select  analog  signals  corre¬ 
sponding  to  the  emalog  or  digital  value  to  be  output.  A  diagram  illustrat¬ 
ing  the  new  design  is  presented  in  Figure  6. 


2.2.3  AC  Reference  Signal 

Generation  of  a  400  Hz  AC  reference  signal  was  incorporated  as  a  new 
ICA  function.  This  signal  is  synthesized  from  the  digital  system  clock 
through  the  use  of  a  counter,  a  sine  table  stored  in  ROM  and  a  D/A  converter 
This  signal  can  be  used  by  subsystems  as  an  AC  reference  thus  eliminating 
the  need  for  external  reference  signals.  Generation  of  the  AC  reference  at 
the  ICA  simplifies  the  synchronization  of  sampling  with  AC  input  signals 
which  must  be  .converted  at  their  peak  value. 


Data  Transfer  Command  Nord: 


15  9  8  7  3  0 


Data  Transfer  Status  Word: 
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Data  Transfer  Handshake: 

1.  LNG  sends  C0  to  IM,  ^eneratinq  an  interrupt 
lA  »  4-bit  Link  Address 

INIT  >  1  to  indicate  initiation  of  message  transfer 

2.  XjMG  performs  read-modify-vrite  on  Si 

FLG  >  1  if  subsystem  is  flagged  as  doun 

HDYO  «  1  if  buffer  0  is  available 

RDYl  «  1  if  buffer  1  is  available 

KECff  *  1  to  indicate  buffer  0  is  being  taken 

REQl  B  1  to  indicate  buffer  1  is  being  taken 

3.  i>iG  writes  S0  to  LH  (output)  or  reads  S0  from  LM  (input) 
WSC  ■  word  subcount,  no.  of  words  being  transferred 

4.  LMG  transfers  data 

5.  LMG  sends  Cl  to  IM,  generating  an  interrupt 


ERR  «  1  if  an  error  was  encountered 

lOB  •  1  to  release  buffer  1,  0  to  release  buffer  0  (single-buffered  1/0) 
REF  B  1  if  buffer  to  be  released  Is  refreshed 

Fioure  4  Data  Transfer  Handshake  Protocol 
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Analog 


MUX 


2.2.4  Synchro  Reference 


Incorporation  of  the  AC  reference  as  part  of  the  ICA  allows  a  group 
configured  for  synchro  operation  to  utilize  the  fourth  channel  to  provide 
the  AC  reference.  This  signal  can  be  connected  to  the  reference  winding  of 
a  synchro. 


2.2.5  Serial  Input  Handshcdce 

A  modification  was  introduced  in  the  hcmdshake  associated  with  the 
flag  mode  of  the  serial  digital  input.  A  flag  mode  transmission  is  initiated 
by  the  subsystem  by  raising  the  flag/acknowledge  line.  A  handshake  is  pro¬ 
vided  by  the  ICA  through  the  request/lockout  line.  A  modification  of  the 
hcmdshake  was  introduced  to  handle  error  occurrences.  With  this  modification, 
the  flag/acknowledge  signal  remains  high  when  an  error  occurs  during  a  trans¬ 
mission  to  the  ICA.  Upon  detecting  an  error,  the  ICA  lowers  the  request/ 
lockout  signal.  This  action  will  not  cause  the  flag/acknowledged  signal  to 
go  low.  The  request/lockout  signal  will  remain  low  for  a  short  period  of 
time  to  reset  the  serial  subsystem.  A  new  transmission  is  initiated  when 
the  request/lockout  signal  goes  high.  A  diagram  illustrating  the  handshake 
modification  is  presented  in  Figure  7. 


2.2.6  Interface  Buffer  Design 

On  the  functional  design,  the  read  and  write  interface  buffers  between 
the  ICA  and  the  LN  were  given  separate  address  assignments.  By  overlapping 
these  addresses  a  reduced  address  space  is  used.  This  feature  does  not  alter 
the  operational  capabilities  of  the  ICA. 


2.2.7  Output  Automatic  Scaling 

Automatic  scaling  of  the  AC  and  DC  reference  with  selection  of  single- 
ended  or  differential  output  was  introduced.  The  automatic  scaling  guarantees 
that  a  digital  value  sent  to  the  D/A  will  produce  am  output  voltage  that  is 
independent  of  the  output  configuration  used  (single-ended  or  differential) . 


2.3  SUBSYSTEM  INFORMATIOI  CHANNEL 

Chamges  in  the  Subsystem  Information  Channel  (SIC)  all  stem  from  the 
decision  to  implement  the  electronic  nameplate  (NP)  with  a  microprocessor. 
Use  of  a  microprocessor  increases  the  flexibility  of  the  NP,  but  does  not 
greatly  change  the  basic  NP  functions.  Principal  chamges  to  the  Fvinctional 
Design  are: 


2.3.1  Nameplate  Clock 

The  clock  signal  to  the  NP  is  always  present  to  enable  operation  of 
the  microprocessor.  Instead  of  stopping  and  starting  the  clock  as  described 
in  sections  5 . 1  and  5 . 3  of  the  Functional  Design ,  amother  line  is  added  to 


ACK/FLftG 

REQ/LOK 


Clock  to 
Subsystem 


(a)  Transmission  with  no  errors 


ACK/FLAG 


REQ/LOK 


Clock  to 
Subsystem 


(b)  Transmission  with  one  error  detected 


Figure  7  Flag  Mode  Serial  Input  Handshake 


the  SIC  bus.  This  line  is  the  RESPONSE/COMMAND  line  and  is  used  to  indicate 
when  a  conmeuid  is  being  transmitted  to  the  NP  and  when  the  NP  is  expected  to 
respond.  The  use  of  this  line  is  illustrated  in  Figure  8. 


2.3.2  Nameplate  Connnands 

Section  5.2  and  Table  9  of  the  Functional  Design  should  be  modified 
to  allow  commands  for  transmitting  more  than  one  word  of  data  at  a  time  be¬ 
tween  the  LM  and  the  NP.  Table  1  provides  a  more  flexible  command  structure 
cuid  would  replace  Table  9  of  the  Functional  Design. 


2.3.3  Nameplate  Architecture 

Because  of  the  microprocessor  implementation,  Figure  31  and  32  in  the 
functional  design  do  not  apply.  Instead,  the  NP  architecture  sinplifies  to 
a  single-chip  microprocessor,  and  the  state  diagram  is  replaced  by  a  NP 
software  flow  chart. 


2.3.4  Ncuneplate  Diagnostic 

The  intelligence  in  the  NP  allows  a  NP  self-diagnostic  to  be  inple- 
mented  by  the  microprocessor,  a  capability  not  provided  for  in  the  Functional 
Design. 
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TABLE  1  NAMEPLATE  COMMANDS 


COMMAND 


RESPONSE 


Instruction 


Status 


1 . 

Select  level 

N/A 

NP  status 

NP  address 

0  NP 

2. 

Select  next  MP 

N/A 

NP  status 

Newly  selected 

NP  address 

3- 

Select  NP  by 

NP  address 

NP  status 

NP  address 

address 

h. 

Deselect  NP 

N/A 

NP  status 

NP  address 

5. 

Assign  NP 
address 

Address  to  be 
ass i gned 

NP  status 

NP  address 

6. 

Read  selected 

NP ' s  address 

N/A 

NP  status 

NP  address 

7. 

Read  selected 
ilP '  s  menory 

Starting  memory 
address,  Number 
of  bytes  wanted 

NP  status 

Starting  memory 
address,  memory 
data 

8. 

Write  enable/ 
disable 

Enabic/d i sable 
flag  (Enable  =1) 

NP  status 

NP  address 

9. 

l-'rite  memory 
data 

Starting  memory 
address.  Number 
of  bytes,  Osta 
bytes 

NP  status 

Starting  memory 
address 

:r-. 

Next  available 
address  to  be 
wr  i  1 1  en 

N/A 

NP  status 

Address  of  next 
avai lable  write 
memory  record 

1 1 . 

Erase  write 

H.'A 

N**  status 

NP  address 

iiiemor  y 

12. 

Run  NP 
d i agnost i c 

N/A 

NP  status 

NP  address 

13. 

Read  NP 
diaqnost ic 
rcsul t  s 

N/A 

NP  status 

Oi  agnost ic 
results 

\>i. 

Reset  selected 
N» 

N/A 

NP  status 

NP  address 

SECTION  3 


IMPLEMENTATION  PLAN 


This  section  describes  a  plan  for  the  development  of  an  RLU  prototype 
euid  its  subsequent  evolution  into  a  set  of  distributed  components  that  can 
be  used  in  future  avionic  system  design.  The  proposed  plan  requires  two 
phases  for  implementation.  The  first  phase  will  be  referred  to  as  the  RLU 
Integration  Phase  and  the  second  the  RLU  Distribution  Phase. 


3.1  OBJECTIVES  AND  APPROACH 

The  program  of  development  outlined  in  this  plan  will  lead  to  the  dis¬ 
semination  of  the  technology  developed  for  the  Remote  Link  Unit  and  will 
facilitate  its  use  in  various  avionic  system  designs.  The  following  objec¬ 
tives  should  be  pursued  in  the  development  of  an  RLU  prototype: 

•  The  RLU  should  be  usable  as  a  universal  maintenance  fixture  that 
will  support  the  maintenance  of  avionic  systems. 

•  The  RLU  should  provide  an  information  interface  that  simplifies 
the  design  of  avionics  systems  and  provides  a  well  defined  sepa¬ 
ration  between  subsystems  and  system  functions. 

•  The  RLU  prototype  should  yield  conponents  that  sinplify  the  design 
of  subsystems  by  providing  information  oriented  interfaces  that 
support  fault  monitoring  and  recording. 

The  above  objectives  can  be  achieved  with  a  program  structured  with  a 
two-phase  development  approach  as  described  in  the  following  sections. 


3.1.1  Phase  I  -  RLU  Integration 

During  this  phase  a  prototype  RLU  would  be  developed  aind  a  program  of 
utilization  of  the  RLU  as  a  maintenance  support  device  would  take  place. 

Development  of  the  RLU  prototype  should  utilize  a  parallel  implemen¬ 
tation  approach  as  illustrated  in  Figure  9.  This  parallel  approach  will 
lead  to  the  development  of  modules  that  can  be  used  independently  of  the 
RLU.  RLUDS  design  manuals  (Part  III)  should  provide  a  basis  for  the  design 
of  the  new  modules. 

A  program  of  utilization  of  the  RLU  as  a  maintenance  console  %du.ch  is 
configured  through  the  use  of  electronic  n^uneplates  should  evolve  with  the 
design  of  the  RLU  prototype.  Diagnostic  programs  stored  in  the  electronic 
nameplates  of  avionic  shop  replaceable  units  (SRUs)  will  be  used  to  configure 
the  RLU  to  perform  its  maintenance  support  function. 

During  this  phase,  a  study  should  be  conducted  to  specify  the  structure 
and  format  of  the  subsystem  data  (information)  stored  in  the  Ul's  shared 
memory.  This  information  should  be  universal  in  nature,  that  is,  it  should 
es^resB  the  value  of  a  variable  in  engineering  units  and  its  representation 
should  be  in  a  standard  floating  point  format.  The  standardization  of  an 
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information  interface  will  enable  the  design  of  system  software  that  is  in¬ 
dependent  of  subsystem  hardware  peculiarities.  This  study  should  recommend 
a  data  format  standard  that  will  render  the  LMG/LM  shared  memory  interface 
as  a  "complete  interface"  according  to  the  definition  presented  in  the 
document  "The  Remote  Link  Unit:  Applications  to  the  Design-f or- Repair 
Methodology  Progreun" ,  [  3  ] . 


3.1.2  Phase  II  -  RLU  Distribution 

During  this  phase,  the  RLU  concepts  will  be  isolated  amd  integrated 
as  components  which  are  compatible  with  the  design  of  subsystems.  Develop¬ 
ment  of  a  con^lete  interface  within  the  RLU  will  facilitate  this  phase  of 
the  program.  Segmentation  of  the  RLU  at  the  con^lete  interface  allows  mov¬ 
ing  the  LM  processing  and  the  complete  interface  to  the  subsystem.  Likewise 
the  LMG  processing  and  interface  can  be  moved  to  the  avionic  system  proces¬ 
sors.  This  decomposition  will  guarantee  that  data  flow  on  the  MIL-STD-1553B 
multiplex  bus  consists  of  pure  information  which  is  independent  of  special 
conversion  codes  associated  with  subsystem  implementations. 

Integration  of  the  LM  functions  with  those  of  an  electronic  nameplate 
leads  to  a  general  purpose  interfacing  module  that  can  be  used  in  the  fab¬ 
rication  of  a  wide  range  of  subsystems.  These  modules  can  interface  directi v 
to  the  multiplex  bus.  A  device  which  integrates  the  features  of  the  link 
module  and  the  electronic  nameplate  has  been  proposed  as  a  viable  solution 
for  process  control  systems  [4). 

Development  of  the  concepts  proposed  for  the  second  pnase  of  this 
plan  will  lead  to  the  design  of  avionic  systems  consisting  of  processors 
and  subsystems  that  interface  directly  to  the  multiplex  bus.  Figure  10 
illustrates  the  architecttire  of  an  avionic  system  utilizing  components  de¬ 
veloped  diiring  this  phase. 

3.2  DESIGN  AND  IMPLEMENTATION  CONSIDERATIONS 

The  design  and  implementation  of  the  RLU  Demonstration  System  has  high¬ 
lighted  design  aspects  which  must  be  further  analyzed  in  the  development  of 
an  RLU  prototype.  These  aspects  will  be  described  as  they  pertain  to  each 
RLU  module  identified  in  the  implementation  plan. 


3.2.1  ICA 

The  ICA  should  be  designed  as  a  single  integrated  circuit  providing 
four  groups  of  interface  ports.  Each  port  must  provide  four  channels  as 
outlined  in  the  functional  design.  The  ICA  will  require  VLSI  technology  to 
achieve  the  high  density  of  con^nents  required  for  its  inplementation. 

A  problem  in  the  design  of  the  ICA  is  the  inplementation  of  the  power 
drivers.  Except  for  the  power  drivers  which  are  bipolar,  all  other  ICA  com¬ 
ponents  utilize  CMOS  technology.  The  high  level  output  current  '‘«mands  by 
synchros  (200  mA)  lead  to  the  bipolar  design  of  the  drivers.  It  is  possible 
that  present  MOS  technology  will  enable  the  drivers  to  be  designed  with  VMOS 
transistors,  thus  eliminating  hybrid  technologies  on  the  ICA  implementation. 


The  ICA  interface  to  the  LM  is  designed  in  tems  of  addressable  re¬ 
gisters  for  operation.  If  the  ICA  is  to  be  used  as  a  stand-alone  universal 
interfacing  device,  the  interface  design  should  be  changed  to  allow  config¬ 
uration  programming  through  hardware  jvui^r  selection.  This  design  option 
may  force  the  deletion  of  certain  ICA  features  in  order  to  accommodate  the 
increased  number  of  external  connections. 


3.2.2  Subsystem  Information  Channel 

The  electronic  nameplate  developed  for  the  RLU  Demonstration  System 
is  very  close  to  a  single  chip  IC  in^lementation.  The  need  for  electrically 
altercdDle  memory  requires  the  replacement  of  EPROM  with  EEPROM.  An  important 
aspect  which  requires  additional  study,  is  the  development  of  a  connector 
which  is  suitable  to  provide  access  to  the  nameplate.  This  connector  should 
allow  for  the  daisy  chaining  of  electronic  nameplates  and  should  be  rugged 
and  small  enough  to  remain  unobstructive  to  subsystem  installation.  A 
minimization  of  the  number  of  lines  in  the  Subsystem  Information  Channel 
should  be  pursued.  The  present  number  of  lines  can  be  reduced  if  the  data, 
clock,  cuid  handshake  signals  are  treuismitted  through  fiberoptics  rather  than 
utilizing  separate  conductors. 

A  study  should  be  conducted  to  establish  appropriate  formats  for  the 
identification,  the  configuration  and  the  maintenance  records  stored  in 
electronic  nameplates.  The  record  formats  utilized  by  the  electronic  name¬ 
plate  developed  for  the  KLUOS  aure  not  adequate  for  use  in  a  final  device. 


3.2.3  Link  Nodule 

Selection  of  am  appropriate  processor  for  the  link  module  should  take 
into  account  the  new  generation  of  microcomputer  chips  that  incorporate 
shared  memory  as  part  of  the  chip.  A  typical  example  of  one  such  device  is 
the  Motorola  68120  processor  which  provides  shared  memory  and  interface 
capacities  which  are  well  suited  for  the  Link  Nodule.  An  efficient  operat¬ 
ing  system  which  takes  advantage  of  the  LM  architecture  and  processing  should 
be  developed. 


3.2.4  Link  Manager 

The  Design  of  the  Link  Manager  should  be  based  on  a  16  bit  processor. 
A  processor  with  the  generic  capabilities  provided  by  the  Motorola  68000 
processor  should  be  used. 

Design  of  the  link  manager  software  should  be  oriented  toward  pro¬ 
viding  an  effective  man-machine  interaction  program.  This  software  would 
facilitate  the  development  of  the  maintenance  port  for  use  in  maintenance 
applications.  The  utilization  of  currently  available  bus  control  interface 
vinits  will  simplify  the  design  of  the  LNG  interface  to  the  multiplex  bus. 


SECTION  4 


TESTS  AND  RESULTS 


A  program  of  tests  was  prepared  to  demonstrate  the  RLU's  functional 
capabilities  and  establish  its  operational  performance.  This  program  was 
designed  to  achieve  the  following  objectives: 

•  Yield  a  test  procedure  to  be  used  for  RLUDS  acceptcmce  at  AFWAL 
upon  delivery. 

•  Provide  a  tool  for  troubleshooting  the  RLUDS  during  system  inte¬ 
gration. 

•  Demonstrate  the  RLU's  basic  operational  features. 

A  brief  description  of  the  test  progr£un  and  a  summary  of  the  test  re¬ 
sults  is  presented  in  the  next  sections. 


4.1  TEST  PROCEDURE 

The  test  program  consists  of  three  parts:  ICA  tests,  SIC  tests,  and 
RLU  tests.  The  first  two  tests  are  device-oriented  tests  associated  with 
the  Interface  Configuration  Adaptor  (ICA)  and  the  Subsystem  Information 
Channel  (SIC).  The  RLU  tests  are  system  level  tests  which  are  designed  to 
demonstrate  the  operational  capabilities  of  the  RLU  in  normal  operation. 


4.1.1  ICA  Tests 


The  ICA  tests  demonstrate  the  caped^ilities  of  the  ICA  to  accept  dis¬ 
tinct  interface  configurations  under  software  control.  All  valid  interface 
configurations  are  tested  on  each  group.  The  tests  configurations  include 
the  following  signal  types: 

a.  d-c  analog  input 

b.  a-c  analog  input 

c.  synchro  input 

d.  discrete  input  (voltage) 

e.  discrete  input  (momentary  and  stable  contacts) 

f.  serial  input  (flag  and  refresh) 

g.  d-c  analog  output 

h.  a-c  analog  output 

i.  synchro  output 

j.  discrete  output  (voltage) 

k.  serial  output 

Each  signal  type  is  tested  with  single-ended  and  differential  con¬ 
nections. 


4.1.2  SIC  Tests 


The  SIC  tests  demonstrate  the  operational  performance  of  all  Subsys¬ 
tem  Information  Channel  confxsnents.  The  components  to  be  tested  include  one 
Nameplate  Interface  Controller  (NIC)  and  t%K>  Electronic  Nameplates  (NP) . 

The  tests  are  performed  by  issuing  commands  to  the  SIC  and  monitoring 
the  resxxinse.  The  following  procedures  are  paurt  of  the  SIC  tests: 

a.  Sequential  addressing 

b.  Random  addressing 

c.  Retrieval  of  NP  directory 

d.  Read/write 

e.  NP  diagnostic 

Valid  and  invalid  commeuids  are  used  in  each  test  to  demonstrate  the 
error  recovery  capability  of  the  SIC. 


4.1.3  RLU  Tests 

The  RLU  tests  demonstrate  the  broad  spectrum  of  capabilities  provided 
by  the  RLU.  These  tests  exercise  the  Link  Module  and  its  interfaces  (Shared 
Memory,  Interface  Configuration  Adaptor  and  Neuneplate  Interface  Controller) 
through  the  various  modes  of  operation  provided  by  the  RLU. 

The  RLU  capabilities  of  self-config\uration,  local  processing,  and 
fault  detection  are  demonstrated  for  two  subsystems: 

•  Serial  subsystem,  and 

•  Synchro  subsystem. 

Each  subsystem  has  an  electronic  nameplate  attached  to  its  enclosure. 
The  electronic  nameplate  stores  identification,  interface  configuration, 
data  conversion  program  and  malfunction  records  of  the  subsystem. 

The  test  procedure  with  each  subsystem  includes  the  following  steps: 

a.  Subsystem  initialization 

b.  Retrieval  of  subsystem  identification  and  interface  configuration 

c.  Uploading  of  data  conversion  program 

d.  Normal  subsystem  operation 

e.  Disruption  of  subsystem  operation  through  an  induced  failure 

f.  Retrieval  of  the  malfunction  record  from  the  subsystem  nameplate 

g.  Resun^tion  of  normal  operation 


4.2  TEST  RESULTS 

During  the  tests  conducted  on  the  RLUDS,  data  was  collected  auid  a  per¬ 
formance  evaluation  was  made  on  all  major  system  components.  A  summary  of 
this  evaluation  is  presented  in  this  section. 


4.2.1  ICA  Tests 


The  ICA  performed  in  accordance  with  design  specifications.  The  re¬ 
solution  in  the  acquisition  of  euialog  input  or  generation  of  output  signals 
is  1  0.1  volt.  This  resolution  is  associated  with  the  use  of  8  bit  A/D  and 
D/A  converters  in  the  RLUDS  ICA.  The  accuracy  of  output  logical  levels  as 
well  as  the  input  logical  threshold  is  ±  0.1  volts. 

The  synchro  signal  levels (A/D  resolution)  allow  the  resolution  of  in¬ 
put  angles  with  an  accuracy  of  ±  1  degree.  The  output  synchro  angle  resolu¬ 
tion  could  not  be  measured  directly  due  to  the  unavailability  of  a  suitable 
control  synchro.  Measurement  of  the  amplitude  ratio  of  the  output  synchro 
voltage  provide  an  estimate  for  the  output  angle  accuracy  to  within  ±  2“. 

The  serial  channels  performed  according  to  specifications  both  with 
correct  transmission  as  well  as  when  errors  resulting  from  wrong  parity 
occurred.  The  maximum  frequency  of  transmission  sustained  by  the  ICA  was 
200  kHz. 


4.2.2  £IC  Tests 

\11  SIC  commemds  were  tested  for  the  nameplate  execution  of  the 
specified  function  cmd  generation  of  the  correct  response.  Table  2  lists 
the  execution  time  for  each  SIC  ccxnmand  as  measured  by  monitoring  the  SIC 
serial  data  bus  line.  The  total  execution  time  was  measured  from  the  start 
bit  of  the  command  to  the  last  stop  bit  of  the  nameplate’s  response.  The 
communication  time  was  measured  with  a  transfer  rate  of  4800  baud. 

Table  3  lists  the  execution  time  of  commands  (write  memory,  erase 
memory,  and  run  diagnostic).  The  execution  time  was  measured  from  the  start 
bit  of  the  command  to  the  time  when  the  "NP  busy"  LED  goes  off  indicating 
the  end  of  processing  for  the  command.  It  is  inportant  to  remember  that 
for  long  commands  the  neuneplate  will  issue  a  comnand  acknowledgement  response 
immediately  upon  receipt  of  the  command  and  then  proceed  to  execute  the 
command. 


4.2.3  LM  Tests 

The  real-time  executive  incorporated  in  the  LM  utilizes  a  round-robin 
scheduler.  The  overhead  introduced  by  the  executive  and  the  time  keeping 
task  was  measiired  to  be  in  the  range  of  1.7  to  1.9  milliseconds. 

The  longest  execution  time  associated  with  any  of  the  U4  tasks  occurs 
when  the  command  interpreter  is  in  execution.  The  execution  time  of  the 
longest  cimmand  response  module  is  40  milliseconds. 


TABIi:  2  SIC  COMMAND  RESPONSE  TIME 


NAMEPLATE 

EXECUTION 

TIME  (in  milliseconds) 

COMMAND 

C0^ffUN  I  CATION 
TINE 

NP  PROCESSING 
TINE 

TOTAL 

1.  Select  level  0  NP 

10.4 

10.6 

21. 

2.  Select  next  NP 

10.4 

10.6 

21. 

3.  Select  NP  by 
address 

12.5 

10.6 

23.1 

4.  Deselect  NP 

10.4 

10.6 

21. 

5.  Assign  NP  address 

12.5 

10.6 

23.1 

6.  Read  selected  NP's 
address 

10.4 

10.6 

21. 

7a,  Read  NP's  memory 
(one  data  byte) 

22.9 

10.6 

33.5 

7b.  Read  NP's  memory 
(2S6  data  bytes) 

SS4.2 

10.6 

564.8 

8.  Write  enable/ 
disable 

12.5 

10.6 

23.1 

9a.  Write  memory 
(one  data  byte) 

20.8 

10.6 

31.4 

9b.  Write  memory 
(14  data  bytes) 

47.9 

10.6 

58.5 

10.  Next  available 
address 

12.5 

10.6 

23.1 

11.  Erase  read/write 
memory 

10.4 

10.6 

21. 

12.  Run  NP  diagnostic 

10.4 

10.6 

21. 

13.  Read  NP  diagnostic 
results 

12.5 

10.6 

23.1 

14.  Abort  selected  NP 

10.4 

10.6 

21. 

TABLE  3  SIC  COMMAND  EXECUTION  TIME 


NANEPLATE  CChWAND 


NP  EXECUTION  COMPLETION  TINE 


Write  memory 
(one  data  byte) 


170  milliseconds^ 


Write  memory 
(14  data  bytes) 

Erase  read/write 
memory 

Run  NP  diagnostic 


852  milliseconds^ 
1.006  seconds^ 

210  milliseconds^ 


NOTES : 

^Each  byte  requires  50  milliseconds  to  be  programmed  into  EPROM.  Then 
are  two  extra  bytes  programmed  in  each  record  in  addition  to  the  data 
bytes. 

^The  erase  pulse  is  designed  to  be  one  second  long. 

^This  is  the  diagnostic  execution  time  without  any  other  command  being 
transmitted  by  the  processor.  This  time  will  increase  as  the  number 
of  commands  sent  during  diagnostic  execution  increases. 


SECTION  5 


CC»ICLUS10NS 


All  program  objectives  for  the  RLU  demonstration  system  were  met.  The 
RLUDS  was  designed,  built,  tested,  and  demonstrated  operational  as  per  speci¬ 
fications.  The  tests  conducted  demonstrated  the  RLU  as  a  feasible  avionic 
system  component. 

The  hardware  and  the  software  design  of  the  RLUDS  is  presented  in  a  set 
of  design  manuals.  These  manuals  provide  detailed  design  information  which 
can  be  used  in  the  development  of  an  RIA)  prototype. 

As  a  result  of  the  RLUDS  implementation,  enhancements  have  been  proposed 
to  the  functional  design  that  will  increase  the  RLU  versatility.  The  imple¬ 
mentation  plan  outlined  in  this  document  proposes  a  phased  approach  to  the 
development  of  an  RLU  prototype  and  the  utilization  of  RLU  concepts  in  avionic 
system  design. 

Implementation  of  the  ICA  and  the  electrcaic  nameplate  as  components 
which  can  be  used  independently  of  the  RLU  creates  a  new  arena  which  should 
be  explored  in  subsequent  studies.  These  studies  should  consider  the  in¬ 
clusion  of  electronic  n^uneplates  and  universal  interfaces  in  the  design  of 
subsystems. 
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